I saw another programming post...

"roflcopter" (roflroflroflcopter)
10/24/2013 at 18:12 • Filed to: because Racecar

Anyone wanna guess what I'm working on?

void loop() {

if(flagPulse == 1) {

//calculates max pulse width

timeCycle = timer2.getCount();

maxpw = timeCycle;

rpm = 60000000 / (timeCycle*5); //calculates rpm

//samples the throttle position sensor and maps it to percentages

throttlePosition = analogRead(16);

throttlePosition = map(throttlePosition, 0, 1023, 0, 100);

ipw = (fuelMap[rpm][throttlePosition]*100); //pulls pulse width from table

//sets the overflow values to the max pulse width at this rpm

timer1.setOverflow(maxpw); timer2.setOverflow(maxpw); timer3.setOverflow(maxpw); timer4.setOverflow(maxpw);

//sets ch1 interrupt to required injector pulse width

timer1.setCompare(TIMER_CH1, ipw); timer2.setCompare(TIMER_CH1, ipw); timer3.setCompare(TIMER_CH1, ipw); timer4.setCompare(TIMER_CH1, ipw);

flagPulse = 0;

}

DISCUSSION (12)

lepie > roflcopter
10/24/2013 at 18:13

megasquirt?

Reading a bit, seems to be an arduino sketch.

Arduino ECU?

roflcopter > lepie
10/24/2013 at 20:05

Close, it's an ARM based micro controller, which means more peripherals and being able to offload all of the timing functionality to hardware. Pretty nifty if I do say so myself.

lepie > roflcopter
10/25/2013 at 02:36

kinda weird, i thought it was an arduino with things such as analogRead() and map(), etc

roflcopter > lepie
10/25/2013 at 09:02

It's set up to program very similar to Arduino. And the board layout can be used with a lot if the Arduino shields, which is a huge plus. But I wouldn't be running cascaded hardware timers with multiple internal interrupts on an Arduino ;)

lepie > roflcopter
10/25/2013 at 14:54

I'd think the new ARM based ones would be powerful enough.

roflcopter > lepie
10/25/2013 at 17:57

It comes down to on-board peripherals... and the ST architecture is more what I'm used to than the Atmel. But to each their own... if you had an Arduino that had the available hardware counters and similar pin-mapping the code would probable run. It's amazing how little the actual processor does on a setup like this though... over 150 lines up setup code just to get the counters configured correctly, then everything is handled through interrupt functions, and the main loop is just what I posted above.

lepie > roflcopter
10/25/2013 at 18:41

I've only played with interrupts on arduinos for non-realtime requirements, but it's a similar setup where you just set an interrupt routine, function, or sub to make it do something and fall back into the loop. I have no idea of the performance on the older AVR based boards, but the newer ARM core ones have a pretty high clock speed. The overhead from the interrupts themselves would be minimal in either case, though.

roflcopter > lepie
10/25/2013 at 19:11

True, it's possible to do it I'm sure.

What I was getting at with the interrupts is that you need to have multiple channels looking at the same counter independently to make it react the way you need to handle multiple cylinders at once. I honestly haven't looked into any of the Arduino stuff enough to know if it can handle it, but I do know that the chip I selected was because it had a lot of those capabilities that others did not.

If I had wanted a more purpose built solution, I would be running a Silicone Labs SI81C586... But then I would have had to design the memory solutions around it, and I'd rather use something that can at least be compatible with existing hardware. Ideally, this will all be adaptable by the end of things and the overall code will be easy enough for people to implement without me walking them through it.

lepie > roflcopter
10/25/2013 at 19:22

Would be easier to do things with an external timer and some shift registers. Just one main heartbeat to the MCU and read out the registers at each cycle.

roflcopter > lepie
10/25/2013 at 19:29

I guess it could be done that way. You'd have to structure the interrupts differently since I currently have the timers setup to trigger each other, in a cascading sort of fashion. I chose to do it that way to make it self-sufficient once it starts, and I can change the pulse widths and the overall timing without it immediately taking effect but instead waiting for the next cycle to substitute the values in. Which means that nothing ever gets cut off mid execution.

lepie > roflcopter
10/25/2013 at 19:31

You could still do that. Output is still PWM from the MCU. All you do is build integers out of the register outputs.

I prefer to do bespoke hardware as much as possible. One big downside is that if there's a bug in it ... break out the soldering iron.

roflcopter > lepie
10/25/2013 at 19:52

Yeah... adaptability is a goal of this project. And this control scheme is technically PWM, but I'm not doing any PWM stuff on the board, I'm taking my own timings every time if that makes sense.